Many web services allow or require users to create accounts with them. For example, a customer of a bank is required to create an online account with the bank to access their bank account information via their web site or their application (“app”). As another example, a news service may allow users to access its news web site or app without creating an account. However, if a user wants to customize the experience with the news web site or app, the user may be allowed to create an account with the news service. When an account is created for a service provider, user credentials are established for accessing the account. The user credentials typically include a user name and password. The service provider may store the user credentials in association with the new account in an account store. To access (e.g., log on to) the account, the user subsequently provides the user credentials to the web site or the application. The service provider, using a process referred to as authentication, checks the account store to ensure that the user credentials are associated with an account. If so, the user is authenticated and allowed to access the account.
The managing of user credentials service provider can place a considerable burden on the service provider. A service provider would need to acquire (e.g., develop or purchase) a software system to manage its user credentials. Both the initial acquisition costs and ongoing maintenance of the software system can be expensive. In addition, the service provider would need to employ sophisticated security techniques to ensure the security of the user credentials, which can also be expensive. If the user credentials of a user are stolen, the thief not only can access the user's account with the service provider's own web site or application, but also may be able to access the user's account with other services. The ability to access the accounts with other services is due, in large part, to users have a tendency to use the same username and password for different web sites and applications, so they only need to remember one set of credentials.
To help relieve the burden on web services to manage user credentials, some web services, referred to as identity providers, manage user credentials on behalf of other web services, referred to as third-party systems. To create a third-party account, the user would need to have an identity provider account with the identity provider with associated user credentials. When a user attempts to create a third-party account, the third-party system directs the user to the identity provider. The identity provider collects the user credentials from the user and checks whether the user credentials are associated with an identity provider account. If they are, the identity provider provides to the third-party system evidence (e.g., a certificate or token signed by a private key of the identity provider) that the user has been authenticated. The third-party system then creates a third-party account and associates it with, for example, the user name used to access the identity provider account. When a user wants to access their third-party account, the third-party system directs the user to the identity provider for authenticating the user based on the user credentials. When the user is authenticated, the identity provider provides to the third-party system evidence that the user has been authenticated. The third-party system then allows the user to access their third-party account. Because the third-party system does not need to store complete user credentials, the third-party system can avoid the expense and risk of managing user credentials. Moreover, since an identity provider provides a specialized service, it may be able to expend considerable resources (i.e., much more than would be feasible for a single service provider) on ensuring the security of user credentials.
Various online service providers, such as social networks and electronic mail providers, also provide identity services to other web services. For example, an email provider may also operate as an identity provider for various electronic commerce web sites. Such identity providers may maintain considerable information about and on behalf of their users. This information can include demographic information, user communications, user-supplied data (e.g., photographs and documents), interaction history, and so on. A user's experience with a third-party system may be improved if the third-party system has access to the information of the user that the identity provider maintains. For example, by accessing demographic information, a news service may be able to present news stories that may be more relevant to the user. As an example, knowledge of the age of the user may be useful in deciding how to position an article about retirement on a display page (e.g., web page).
Because of privacy concerns, an identity provider typically requires a user to consent to the sharing of the information associated with the user's account with a third-party system. The identity provider may also allow the user to specify the scope of the consent by identifying what type of information can be shared with the third-party system. For example, a user may consent (or give permission) to share their demographic information and communications, but not their pictures. The scope of consent that a user designates may be different for different web services. For example, a user may consent to share pictures with a photo-processing web service, but not with a banking web service. When a user goes directly to an identity provider and creates an account, the identity provider would typically not have any reason to obtain consent to share information with any third-party system. Thus, the account-creation user experience, when creating the identity provider account, would not request a scope of consent. However, when a user is directed to an identity provider by a third-party system, the scope of consent for that third-party system would need to be requested. In such a case, the identity provider provides an account-creation user experience (i.e., the same as used when not directed by a third-party system) and then provides a scope-of-consent user experience. Identity providers desire to provide a user experience that both makes the creating of an identity provider account as simple and as fast as possible for the user and minimizes the computational resources (e.g., network traffic) needed to create an account.